Regarding the current status of message level security in web services, various standards like web service security (WS-Security) along with web service policy (WS-Policy) play a central role. Although such standards are suitable for ensuring so-called end-to-end message level security as opposed to so-called point-to-point security, certain attacks may still occur.
Web service specifications have been designed with the aim of being composable to provide a rich set of tools for secure, reliable, and/or transacted web services. The so-called SOAP (simple object access protocol) is a possible way for a program running in one kind of operating system to communicate with a program in the same or another kind of an operating system by using the world wide web's hypertext transfer protocol (HTTP) and its extensible markup language (XML) as the mechanisms for information exchange. Since web protocols are installed and available for use on all major system platforms, HTTP and XML provide an already at-hand solution to the problem of how programs running under different operation systems in a network can communicate with each other. SOAP specifies exactly how to encode an HTTP header and an XML file, so that a program in one computer can call a program in another computer and deposit information. It also specifies how the called program can return response.
Due to the flexibility of SOAP-level security mechanisms, web services may be vulnerable to a distinct class of attacks based on a malicious interception, manipulation and transmission of SOAP messages, which may be referred to as XML rewriting attacks. The problem of XML rewriting attacks is described in detail, for example, in K. Bhargavan, C. Fournet, A. D. Gordon, and G. O'Shea, “An Advisor for Web Services Security Policies,” Proceedings of the ACM Workshop on Secure Web Services, Nov. 11, 2005. Although the already mentioned web service security (WS-Security) and web service policy (WS-Policy) and other related standards theoretically can prevent XML rewriting attacks in practice, incorrect use of these standards may make web services vulnerable to XML rewriting attacks.
All web service specifications security related specifications, however, introduce new headers in SOAP messages. So concerns about the operational performance of web services security are legitimate because added XML security elements not only make use of more network bandwidth but also demand additional CPU (Central Processing Unit) cycles at both the sender side and the receiver side. Therefore, a generation and validation of a key security mechanism, e.g. signature, are always processor intensive tasks. Therefore, it is desirable to examine the performance issue of web services security.
Security protocols, described using web service specifications, are getting more complex day by day. Researchers are applying formal methods to verify and secure the protocols' and specifications' goals. As new vulnerabilities are exposed, these specifications continue to evolve.
The so-called Microsoft's SAMOA project represents an example effort where web services specifications are analyzed using rigorous formal techniques. One of the focus areas of the SAMOA project is to identify common security vulnerabilities during security reviews of web services with policy-driven security.
In the paper by Bhargavan, et al., referenced above, titled “An Advisor for Web Services Security Policies,” the authors describe the design of an advisor for web services security configurations, the first tool both to identify such vulnerabilities automatically and to offer remedial advice. While one of their previous works, which is described in K. Bhargavan, C. Fournet, and A. D. Gordon, “Verifying policy-based security for web services,” 11th ACM Conference on Computer and Communications Security (CCS '04), pages 268-277, October 2004,” may be used to generate and analyze web services security policies to be aware for vulnerabilities to XML rewriting attacks, this tool is able to bridge the gap between formal analysis and implementation. Moreover, the just-referenced paper describes a formal semantics for web service security policy (WS-Security Policy) and proposes an abstract link language (described in K. Bhargavan, C. Fournet, A. D. Gordon, and R. Pucella, “TulaFale: A security tool for web services,” International Symposium on Formal Methods for Components and Objects (FMCO '03), LNCS. Springer, 2004”) for specifying the security goals of web services and their clients. They present the architecture and implementation of fully automatic tools to compile policy files from link specifications and to verify by evoking a theorem prover (described, for example, in B. Blanchet, “An efficient cryptographic protocol verifier based on Prolog rules. In Proceedings of the 14th IEEE Computer Security Foundations Workshop, pages 82-96. IEEE Computer Society Press, 2001”) whether a set of policy files run by any number of senders and receivers correctly implements the goals of a link specification, in spite of active attackers.
Note that policy-driven web services implementations are prone to the useful subtle vulnerabilities associated with cryptographic protocols. These tools help prevent such vulnerabilities, as policies can be verified when first compiled from link specifications, and also can be re-verified against their original goals after any modifications during deployment.
The assumptions with all these formalizations are that the attacker can compose messages, replay them, or decipher them only if it knows the right key, but cannot otherwise decrypt the encrypted messages. These formalizations do not model insider attacks; in fact principals with shared keys are assumed well-behaved.
Web service security specification(s) are available that may be used to define an end-to-end security framework that provides support for intermediary security processing. Message integrity may be provided by using known XML signature(s) in conjunction with security tokens to ensure that messages are transmitted without modifications. Message confidentiality is granted by using XML encryption in conjunction with security tokens to keep portions of SOAP messages confidential. Web service security seeks to encapsulate the security interactions described above within a set of security headers.
Web service policy is essentially a logical predicate on SOAP messages over base assertions, determining which message parts must be present, signed or encrypted. A standard policy framework would make it possible for developers to express the policies of services in a machine-readable way. Web services infrastructure could be enhanced to understand certain policies and enforce them at runtime. The policy framework currently expressed by web service policy (WS-Policy) requires the definition of policy “Assertions” (predicates) for each domain to which policy is to be applied.
Three examples of specifications defining such assertions have been published hitherto:
1. “WS-PolicyAssertions” (described in T. Nadalin, et al., “WS-PolicyAssertions, 28 May 2003) defining some general-purpose assertions,
2. “WS-SecurityPolicy” (described in T. Nadalin, et al., “Web Services Security Policy Language (WS-SecurityPolicy), Version 1.0, 18 Dec. 2002”), defining policy assertions for web service security and other specifications that might cover the same message security space, and
3. “WS-ReliabilityPolicy” (described in Stefan Batres, et al., “Web Services Reliable Messaging Policy Assertion (WS-RM Policy)”, February 2005), defining policy assertions for web service reliability, and other specifications that might cover the same reliable messaging space.
WS-SecurityPolicy1.0 may be built on the WS-Policy (WS-Policy as described in Bajaj, et al., “Web Services Policy Framework (WS-Policy),” September 2004) and WS-PolicyAssertion is a declarative XML format for programming how web services implementations construct and check web service security headers. It expresses policy in terms of individual headers on individual messages. It defines two base assertions for integrity and confidentiality. The more recent version WS-SecurityPolicy1.1 expresses policy in terms of higher-level message patterns.
XML digital signatures specification may generally specify how to describe, attach, and validate a digital signature using XML. The “Signature” element is the primary construct of the XML digital signature specification. The signature is generated from a hash over the canonical form of the manifest, which can reference multiple XML documents. Canonicalization means to put a structure in a standard format that is generally used. The “SignedInfo” element is the manifest that is actually signed. This data is sequentially processed through several steps on the way to becoming signed.
XML canonical forms states that XML documents though being logically equivalent within an application context may differ in physical representations based on XML permissible syntactic changes. These changes, for example, can be attribute ordering, entity references or character encoding. Basically this is a process of applying standard algorithms to generate a physical representation of an XML document. In XML security, there is a standard mechanism to produce an identical input to digestion procedure prior to both signature generation and signature verification. Given its necessity, the speed of canonicalization will have an impact on the overall performance of SOAP security.
Considering the above described state of the art, various web service specifications as described in G. Della-Libera, M. Gudgin, P. Hallam-Baker, M. Hondo, H. Granqvist, C. Kaler, H. Maruyama, M. McIntosh, A. Nadalin, N. Nagaratnam, R. Philpott, H. Prafullchandra, J. Shewchuk, D. Walter, and R. Zolfonoon, “Web services security policy language (WS-SecurityPolicy), July 2005. However, a number of limitations to their applicability in secure web services can be identified.
Since all the proposed standards are only frameworks, they do not mandate any guarantee that using WS-security provides the absolute security; rather if used incorrectly web services would be vulnerable to XML rewriting attacks.
It seems not to be realistic to capture all security needs within a simple declarative syntax. In order to handle each assertion, a policy processor must incorporate a domain-specific code module that understands the interpretation of that assertion as defined in a domain-specific specification. The interpretation is subject to human error, so without strict conformance tests, different implementations of a processor for each assertion may not be consistent.
Policy files need to be validated on application start-up, because if a policy file is compromised then malicious SOAP messages could be transported.
Enforcing a policy is totally domain dependent and it is a must. The strongest policy may be useless if it is not applied to the right message. An enforcement of the policy for intermediaries is yet to be standardized. Furthermore, there is a lack of standardization to retrieve policy for sender or receiver.
The digital signature references message parts by their Id attributes (Identity attributes), but says nothing of their location in the corresponding message. So an attacker can rewrite the message part placing it in a new header keeping the reference valid.
The message identifier is optional according to WS-Addressing as described in “Web Service Addressing (WS-Addressing) W3C Member Submission 10 Aug. 2004,” but is generally included in a request if a reply is expected. All the above mentioned limitations may directly affect the security and the performance of the web services.
The presence of a hostile opponent who can observe all the network traffic and is able to send any fraudulent messages meeting the protocol requirements must always be assumed. So the already mentioned SOAP messages, for example, are vulnerable to a distinct class of attacks by an attacker placed in between any two legitimate SOAP nodes, e.g. sender, intermediaries and ultimate receiver. The attacker intercepts the message, manipulates it and may transmit it. These kinds of attacks are called XML rewriting attacks and are described in detail herein reference. It can be stated that XML rewriting attacks follow two patterns in general. The patterns give indication about a security loophole.
The first pattern can be called SOAP Extensibility Exploitation. In this case the attacker generates new SOAP elements and adds those into the corresponding message, keeping it well formed. Consequently malicious data may be transported.
The second pattern can be described as “Copy & Paste”. In this case, the attacker copies parts of a message into other parts of that message or into completely new messages, which may be generated using the previous pattern.
The attacker is able to forge message parts and tricks a recipient in a way, that it is impossible to detect any tampering if the standards, e.g. WS-Security, WS-Policy, WS-SecurityPolicy, are not used carefully. An important observation here is that not the cryptographic technique used as part of the standard has been broken but that the SOAP message structure has been exploited by an attacker. As already mentioned above, the digital signature references message parts by their Id attributes but says nothing of their location in the message. So an attacker can rewrite the message part placing it in a new header keeping the reference valid.
Methodical usage of WS-Policy, WS-PolicyAssertion, and WS-SecurityPolicy resists these attacks, however, such methodical usage may be difficult to implement in a consistent, practical, reliable way.